Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

This does not mean you should start giving variables incomprehensible names, drop indentation that shows program structure, and stop using comments. It simply means you can use more complicated algorithms that you might have avoided earlier out of fear of complexity.

As the application matures, realign priorities accordingly.

Defer Optimization

Many programmers concentrate only on speed and memory usage. Unfortunately, these are usually far less important than readability, maintainability, and robustness, at least during the early stages of the project.

Typically, 90 percent of a program’s time is spent in 10 percent of the code. Similarly, most of a program’s memory use is often localized in a small number of routines and data structures. If you go to great lengths to optimize speed and memory use in every part of the program, 90 percent of your work is spent on code that does not need the extra effort.

Even worse, optimizing every part of the program makes much of the code more complicated, less understandable, and more likely to contain bugs. Not only does 90 percent of your work fail to make the application significantly faster or smaller, but it also makes matters worse by generating more bugs.

Initially, you should concentrate on making code bug free, understandable, testable, and maintainable. Later, when the project is almost finished, you can run tests to determine which code needs optimization. After you find the 10 percent of the code that takes 90 percent of the time, you can concentrate on improving only that code. You do not waste your time optimizing the other 90 percent of the code and you avoid all the bugs that premature optimization would have caused.

Deferring optimization also means that bugs created during optimization are introduced late in the project. The longer a bug remains hidden before it is detected, the harder it is to find and fix. Because the optimization bugs are introduced late in the project, you cannot have written a lot of code that depends on these bugs. That makes the bugs easier to find and repair.

Don’t Optimize

For many years after their invention, computers were extremely expensive. A computer that was powerful enough to be useful cost millions of dollars. In comparison, programmers were cheap.

Today, computers are relatively cheap and programmers are very expensive. If a program is not fast enough, installing new memory or buying a faster computer are reasonable options. Unless the program will be used on hundreds of computers, it will be cheaper to buy more hardware than to make a programmer spend more than a few hours optimizing the program’s code.

If an application’s performance is adequate, do not optimize it. You will save not only the unnecessary optimization time, but also the time to fix the bugs optimization causes.

Get It Working First

High-quality code makes scheduling much easier. Suppose you have a project in which 90 percent of the code is written but riddled with bugs. Guessing when the last bug will be fixed is impossible. You cannot predict when the code will be working, which features will be working first, and when the finished application will be ready for release.

Contrast that with a project in which 50 percent of the code is written but it is very high quality and has almost no bugs. In that case you can predict with some confidence that the coding phase is about halfway finished. Since the team writes high-quality code, you know from your schedule which features will be working first. You may even be able to rearrange the schedule somewhat to change the order in which items are finished. After you include enough time for adequate testing, you can predict when the finished application will be ready for release.

A partial implementation that works is also better than a complete implementation that is full of bugs. Suppose one application is nearly complete but it crashes every five minutes. Another application is only half-functional, but that half is flawless. Menu items and buttons for features that are not yet implemented are disabled. People will perceive the second as the better, more professional application. If you doubt that, think about which you would rather demonstrate to your company’s president.

Get the application working properly first. Then optimize it. Make sure each piece is working before you move on to the next.

Be Steady and Thorough

A programming adage states, “There’s never time to do it right, but there’s always time to do it again.” If you rush through development to meet deadlines, you may do shoddy work. You make mistakes you would have avoided had you spent enough time to properly design, code, and test the program. Instead of finishing the project a little late, you may finish on time with a program so full of bugs it is worthless. You then need to rework the code again and again until you fix enough bugs so that the program is usable.

Be steady and thorough, not fast and careless. In programming, even more than in many other occupations, haste makes waste. Build a routine, test it thoroughly, and move on to something else. Do not rush frantically from task to task, trying to get as much done as possible as quickly as possible. If you take the time to ensure that your routines are bug-free when you write them, you will not need to debug them later.

On the other hand, unlike the tortoise in the fable “The Tortoise and the Hare,” you do not need to be slow and steady. It is fine to be fast, as long as you are thorough. Design a routine, implement it, test it thoroughly, and then move on to the next task.

Code Offensively

For many years, programmers have been taught to code defensively. Defensive coding means writing a routine so it can handle a wide variety of possible strange or incorrect inputs without crashing. For instance, consider the following implementation of the factorial function:

Public Function Factorial(num As Integer)
     If num = 0 Then
        Factorial = 1
    Else
        Factorial = num * Factorial(num - 1)
    End If
End Function

This routine enters an infinite recursion if its parameter num is less than 0. If the parameter is –1, the program calls Factorial(–1), which calls Factorial(–2), which calls Factorial(–3), and so forth until the program exhausts the system stack and crashes.

The traditional defensive version of this routine uses an inequality test to catch cases where the parameter is less than 0.

Public Function Factorial(num As Integer)
     If num <= 0 Then
        Factorial = 1
    Else
        Factorial = num * Factorial(num - 1)
    End If
End Function

This defensive version allows the Factorial function to continue running when it receives an invalid input. Unfortunately, it also silently hides a probable bug. Factorials are not defined for numbers less than 0. If the calling routine executes Factorial(–1), it probably contains a bug. The defensive version of the Factorial function hides the bug by continuing to execute as if the parameter were valid.